X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C73E6E.AD7EE1F6@onstor-exch02.onstor.net>; Mon, 22 Jan 2007 13:45:48 -0800
MIME-Version: 1.0
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C73E6E.AD7EE1F6"
Subject: RE:  RE: Functional Spec : Increase the number of TCP connections - for review
Date: Mon, 22 Jan 2007 13:45:47 -0800
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E02228C21@onstor-exch02.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E028FDA@onstor-exch02.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic:  RE: Functional Spec : Increase the number of TCP connections - for review
thread-index: Acc83H7MadyOqtJqQluj02kZHxGfjAAHozGwAFjFkyAAA/+80A==
References: <BB375AF679D4A34E9CA8DFA650E2B04E0222879B@onstor-exch02.onstor.net> <BB375AF679D4A34E9CA8DFA650E2B04E028FDA@onstor-exch02.onstor.net>
From: "Jonathan Goldick" <jonathan.goldick@onstor.com>
To: "Shamsudeen Jeseem" <jeseem@onstor.com>,
	"dl-Design Review" <dl-designreview@onstor.com>,
	"Narayan Venkat" <narayan.venkat@onstor.com>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C73E6E.AD7EE1F6
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

See JG>

_____________________________________________
From: Shamsudeen Jeseem=20
Sent: Monday, January 22, 2007 12:08 PM
To: Jonathan Goldick; dl-Design Review; Narayan Venkat
Subject: RE: RE: Functional Spec : Increase the number of TCP
connections - for review

Hi Jonathan,
	Will update the FS.
Pls. see the other comments. ( points not commented are where I would
update the FS. On others waiting for input)

_____________________________________________
From: Jonathan Goldick=20
Sent: Saturday, January 20, 2007 5:26 PM
To: Shamsudeen Jeseem; dl-Design Review; Narayan Venkat
Subject: RE: Functional Spec : Increase the number of TCP connections -
for review

1.	Update the copyright to 2007.  Jay made a new template somewhere
with all this stuff handled.
2.	In section 1, there is a typo in the MRD link, you have an extra
space in front of "Delorean MRD-PRD-REV1-7.xls"
3.	In section 4, is Cheetah really not required?  I only ask
because the MRD mentions Nissho by name and their customers have
Cheetah(s).  Narayan, please comment.
4.	In section 4, is CLUSDB_REC_TYPE_CORE_DUMP a typo?  I'm missing
why we would put this under core dump but perhaps this relates to the
comment in section 7 about avoiding a migration; it just seems confusing
so I thought I'd ask.  Anyways, is it really required that we make this
configurable?  Perhaps it's acceptable to just detect the model number
and set the value?  If we could make this hard-wired per model number
then we could cut out a number of the tasks and make this an easier
project and test effort.  Narayan, please comment.
	[jes]  since we want to store only 4 bytes per filer, didn't
make sense to add a new record type and increase clusterDB size. Also we
will have had to define upgrade path.
	CLUSDB_REC_TYPE_CORE_DUMP was the only per filer record in
clusterDB, that we found was zero-initialized and so usable.=20
JG> We are making a number of cluster DB changes in this release so it
would in fact be better to make a new record if we make this
configurable.  However, I think that it should be hardwired per model
number.  I'm not saying we preallocate the worst-case number of
structures but I just don't see customers wanting to change this number
up and down, and really don't want to have to do all this extra work to
support it.  It seems much more important to get the networking and
application-layer work complete to get things scaled up.
=09
	Hard-wiring per model number : increasing the connection count
would have a memory overhead, since we currently pre-allocate connection
structs, mbufs, tcp stats in ssc. Hence wanted to make this
configurable.
	Implementation wise, presently planning to copy this as bootup
environment to TXRX (which persists across reboots), so maynot be more
difficult than detecting hardware model, only more flexible to user.
=09
5.	Can we make section 7.1 its own major section since testing is
not really a sub-chapter of Migration Strategy?
6.	In section 7.1, can we add a test where we send some load, even
if it's low, across all the connections?  We need to know if the number
of Ops we can service changes dramatically if the load is spread across
a lot of connections versus our normal tests with very few connections.
7.	In section 7.1, we probably should add a statement that we are
not able to make sure that this many connections will work properly with
LinkAggregation set up.  While inn practice I would expect customers to
use something to spread such a huge load around, we just don't have the
infrastructure to simulate that number of clients in a way that
exercises LinkAggregation.  This is probably more of a test about
whether the switches actually function properly anyways.
8.	Once you get all of this working in a networking sense we need
to determine whether it works in practice with so many CIFS or NFS
connections.  If we could handle 1000 CIFS logons with Kerberos in 10
seconds(making this number up for discussion purposes) then 32K CIFS
connections is about 5 minutes and makes sense, but is 128K really
achievable and across how much time would we have to spread the initial
connects to avoid overloading the auth-agent?  There is a similar issue
for NFS mounts with non-trivial export options (NIS netgroups).  While
what you are proposing looks pretty complete from a networking (NCPU)
layer, I think we need more on the CIFS/NFS/Auth-Agent layer changes
that might be required to make such a large number of connections
actually usable.
	[jes] quite true. 128k connections wouldn't make much sense.
(apart from sales pitch).
JG> Maybe so, but we do need to spend some cycles making sure that even
32K works reliably at the CIFS/NFS layers and not just on the networking
side,



------_=_NextPart_001_01C73E6E.AD7EE1F6
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7650.28">
<TITLE>RE:  RE: Functional Spec : Increase the number of TCP connections =
- for review</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P DIR=3DLTR><SPAN LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT =
COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">See JG&gt;</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT =
SIZE=3D2 =
FACE=3D"Tahoma">_____________________________________________<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"><B></B></SPAN><SPAN =
LANG=3D"en-us"><B><FONT SIZE=3D2 =
FACE=3D"Tahoma">From:</FONT></B></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Tahoma"> Shamsudeen Jeseem<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"><B></B></SPAN><SPAN =
LANG=3D"en-us"><B><FONT SIZE=3D2 =
FACE=3D"Tahoma">Sent:</FONT></B></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Tahoma"> Monday, January 22, 2007 =
12:08 PM<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"><B></B></SPAN><SPAN =
LANG=3D"en-us"><B><FONT SIZE=3D2 =
FACE=3D"Tahoma">To:</FONT></B></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Tahoma"></FONT> <FONT SIZE=3D2 =
FACE=3D"Tahoma">Jonathan Goldick; dl-Design Review; Narayan Venkat<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"><B></B></SPAN><SPAN =
LANG=3D"en-us"><B><FONT SIZE=3D2 =
FACE=3D"Tahoma">Subject:</FONT></B></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Tahoma"> RE: RE: Functional Spec : Increase the number of TCP =
connections - for review</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT =
COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">Hi Jonathan,</FONT></SPAN></P>

<P DIR=3DLTR><SPAN =
LANG=3D"en-us">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">Will update the =
FS.</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">Pls. see the other comments. ( points not commented are =
where</FONT> <FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">I would =
update the FS. On others waiting for input)</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT =
SIZE=3D2>_____________________________________________<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"><B></B></SPAN><SPAN =
LANG=3D"en-us"><B></B></SPAN><B><SPAN LANG=3D"en-us"><FONT =
SIZE=3D2>From:</FONT></SPAN></B><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT SIZE=3D2> Jonathan =
Goldick<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"><B></B></SPAN><SPAN =
LANG=3D"en-us"><B></B></SPAN><B><SPAN LANG=3D"en-us"><FONT =
SIZE=3D2>Sent:</FONT></SPAN></B><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT SIZE=3D2> Saturday, =
January 20, 2007 5:26 PM<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"><B></B></SPAN><SPAN =
LANG=3D"en-us"><B></B></SPAN><B><SPAN LANG=3D"en-us"><FONT =
SIZE=3D2>To:</FONT></SPAN></B><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT SIZE=3D2> Shamsudeen =
Jeseem; dl-Design Review; Narayan Venkat<BR>
</FONT></SPAN><SPAN LANG=3D"en-us"><B></B></SPAN><SPAN =
LANG=3D"en-us"><B></B></SPAN><B><SPAN LANG=3D"en-us"><FONT =
SIZE=3D2>Subject:</FONT></SPAN></B><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"><FONT SIZE=3D2> RE: =
Functional Spec : Increase the number of TCP connections - for =
review</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">1.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"> =
<FONT SIZE=3D2 FACE=3D"Courier New">Update the copyright to 2007.&nbsp; =
Jay made a new template somewhere with all this stuff =
handled.</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">2.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></SPAN><SPAN LANG=3D"en-us"> =
<FONT SIZE=3D2 FACE=3D"Courier New">In section 1, there is a typo in the =
MRD link, you have an extra space in front of &#8220;Delorean =
MRD-PRD-REV1-7.</FONT><FONT SIZE=3D2 FACE=3D"Courier =
New">xls&#8221;</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">3.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></SPAN><SPAN LANG=3D"en-us"> =
<FONT SIZE=3D2 FACE=3D"Courier New">In section 4, is Cheetah really not =
required?&nbsp; I only ask because the MRD mentions Nissho by name and =
their customers have Cheetah(s).&nbsp;</FONT></SPAN><SPAN =
LANG=3D"en-us"> <FONT COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Courier =
New">Narayan, please comment.</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">4.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></SPAN><SPAN LANG=3D"en-us"> =
<FONT SIZE=3D2 FACE=3D"Courier New">In section 4, is =
CLUSDB_REC_TYPE_CORE_DUMP a typo?&nbsp; I'm missing why we would put =
thi</FONT><FONT SIZE=3D2 FACE=3D"Courier New">s under core dump but =
perhaps this relates to the comment in section 7 about avoiding a =
migration; it just seems confusing so I thought I</FONT><FONT SIZE=3D2 =
FACE=3D"Courier New">&#8217;</FONT><FONT SIZE=3D2 FACE=3D"Courier New">d =
ask.&nbsp; Anyways, is it really required that we make this =
configurable?&nbsp; Perhaps it</FONT><FONT SIZE=3D2 FACE=3D"Courier =
New">&#8217;</FONT><FONT SIZE=3D2 FACE=3D"Courier New">s acceptable to =
just detect the mo</FONT><FONT SIZE=3D2 FACE=3D"Courier =
New">d</FONT><FONT SIZE=3D2 FACE=3D"Courier New">el number and set the =
value?&nbsp; If we could make this hard-wired per model number then we =
could cut out a number of the tasks and make this an easier project and =
test effort.&nbsp;</FONT></SPAN><SPAN LANG=3D"en-us"> <FONT =
COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Courier New">Narayan, please =
comment.</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN></P>
<UL DIR=3DLTR>
<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT COLOR=3D"#3366FF" SIZE=3D2 =
FACE=3D"Arial">[jes]&nbsp; since we want to store only 4 bytes per =
filer, did</FONT><FONT COLOR=3D"#3366FF" SIZE=3D2 =
FACE=3D"Arial">n</FONT><FONT COLOR=3D"#3366FF" SIZE=3D2 =
FACE=3D"Arial">&#8217;</FONT><FONT COLOR=3D"#3366FF" SIZE=3D2 =
FACE=3D"Arial">t make sense to add a new record type and increase =
clusterDB size. Also we will have had to define upgrade =
path.</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT COLOR=3D"#3366FF" SIZE=3D2 =
FACE=3D"Arial">CLUSDB_REC_TYPE_CORE_DUMP was the only per filer record =
in clusterDB, that we found was zero-initialized and so =
usable.</FONT><FONT COLOR=3D"#3366FF" SIZE=3D2 =
FACE=3D"Arial"></FONT></SPAN><SPAN LANG=3D"en-us"> </SPAN></P>
</UL>
<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">JG&gt; We are making a number of cluster DB changes in =
this release so it would in fact be better to make a new record if we =
make this configurable.</FONT>&nbsp;<FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial"></FONT> <FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">H</FONT><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">owever, I think that it should be hardwired per model =
number.</FONT>&nbsp;<FONT COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial"> =
I</FONT></SPAN><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">&#8217;</FONT></SPAN><SPAN LANG=3D"en-us"><FONT =
COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">m not saying we preallocate =
the worst-case number of structures but I just don</FONT></SPAN><SPAN =
LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">&#8217;</FONT></SPAN><SPAN LANG=3D"en-us"><FONT =
COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">t see customers wanting to =
change this number up and down, and really don</FONT></SPAN><SPAN =
LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">&#8217;</FONT></SPAN><SPAN LANG=3D"en-us"><FONT =
COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">t want to have to do all this =
extra work to support it.</FONT></SPAN><SPAN LANG=3D"en-us">&nbsp;<FONT =
COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial"> I</FONT><FONT =
COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">t</FONT><FONT =
COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial"> seems much more important to =
get the networking and application-layer work complete to get things =
scaled up.</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN></P>
<UL DIR=3DLTR>
<P DIR=3DLTR><SPAN LANG=3D"en-us"></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT COLOR=3D"#3366FF" SIZE=3D2 =
FACE=3D"Arial">Hard-</FONT><FONT COLOR=3D"#3366FF" SIZE=3D2 =
FACE=3D"Arial">wiring per model number : increasing the connection count =
would have a memory overhead, since we currently pre-allocate connection =
structs, mbufs, tcp stats in ssc. Hence wanted to make this =
configurable.</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT COLOR=3D"#3366FF" SIZE=3D2 =
FACE=3D"Arial">Implementation wise, presently planning to copy =
thi</FONT><FONT COLOR=3D"#3366FF" SIZE=3D2 FACE=3D"Arial">s as bootup =
environment to TXRX (which persists across reboots), so maynot be more =
difficult than detecting hardware model, only more flexible to =
user.</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"></SPAN></P>
</UL>
<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">5.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></SPAN><SPAN LANG=3D"en-us"> =
<FONT SIZE=3D2 FACE=3D"Courier New">Can we make section 7.1 its own =
major section since testing is not really a sub-chapter of =
Migration</FONT><FONT SIZE=3D2 FACE=3D"Courier New"> =
Strategy?</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">6.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT> <FONT SIZE=3D2 =
FACE=3D"Courier New">In section 7.1, can we add a test where we send =
some load, even if it</FONT><FONT SIZE=3D2 FACE=3D"Courier =
New">&#8217;</FONT><FONT SIZE=3D2 FACE=3D"Courier New">s low, across all =
the connections?&nbsp; We need to know if the number of Ops we can =
service changes dramatically if the load is spread across a lot of =
connections versus our no</FONT><FONT SIZE=3D2 FACE=3D"Courier New">rmal =
tests with very few connections.</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">7.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT> <FONT SIZE=3D2 =
FACE=3D"Courier New">In section 7.1, we probably should add a statement =
that we are not able to make sure that this many connections will work =
properly with LinkAggregation set up.&nbsp; While inn practice I would =
expect customers to use som</FONT><FONT SIZE=3D2 FACE=3D"Courier =
New">ething to spread such a huge load around, we just don</FONT><FONT =
SIZE=3D2 FACE=3D"Courier New">&#8217;</FONT><FONT SIZE=3D2 =
FACE=3D"Courier New">t have the infrastructure to simulate that number =
of clients in a way that exercises LinkAggregation.&nbsp; This is =
probably more of a test about whether the switches actually function =
properly anyways.</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">8.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT> <FONT SIZE=3D2 =
FACE=3D"Courier New">O</FONT><FONT SIZE=3D2 FACE=3D"Courier New">nce you =
get all of this working in a networking sense we need to determine =
whether it works in practice with so many CIFS or NFS connections.&nbsp; =
If we could handle 1000 CIFS logons with Kerberos in 10 seconds(making =
this number up for discussion purposes) t</FONT><FONT SIZE=3D2 =
FACE=3D"Courier New">h</FONT><FONT SIZE=3D2 FACE=3D"Courier New">en 32K =
CIFS connections is about 5 minutes and makes sense, but is 128K really =
achievable and across how much time would we have to spread the initial =
connects to avoid overloading the auth-agent?&nbsp; There is a similar =
issue for NFS mounts with non-trivial</FONT> <FONT SIZE=3D2 =
FACE=3D"Courier New">e</FONT><FONT SIZE=3D2 FACE=3D"Courier New">xport =
options (NIS netgroups).&nbsp; While what you are proposing looks pretty =
complete from a networking (NCPU) layer, I think we need more on the =
CIFS/NFS/Auth-Agent layer changes that might be required to make such a =
large number of connections actually usa</FONT><FONT SIZE=3D2 =
FACE=3D"Courier New">b</FONT><FONT SIZE=3D2 FACE=3D"Courier =
New">le.</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN></P>
<UL DIR=3DLTR>
<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT COLOR=3D"#3366FF" SIZE=3D2 =
FACE=3D"Arial">[jes] quite true. 128k connections wouldn</FONT><FONT =
COLOR=3D"#3366FF" SIZE=3D2 FACE=3D"Arial">&#8217;</FONT><FONT =
COLOR=3D"#3366FF" SIZE=3D2 FACE=3D"Arial">t make much sense.</FONT> =
<FONT COLOR=3D"#3366FF" SIZE=3D2 FACE=3D"Arial">(apart from sales =
pitch).</FONT></SPAN><SPAN LANG=3D"en-us"></SPAN></P>
</UL>
<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000080" SIZE=3D2 =
FACE=3D"Arial">JG&gt; Maybe so, but we do need to spend some cycles =
making sure that even 32K</FONT></SPAN><SPAN LANG=3D"en-us"> <FONT =
COLOR=3D"#000080" SIZE=3D2 FACE=3D"Arial">works reliably at the CIFS/NFS =
layers and not just on the networking side,</FONT></SPAN><SPAN =
LANG=3D"en-us"></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"></SPAN><SPAN =
LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"></SPAN></P>

</BODY>
</HTML>
------_=_NextPart_001_01C73E6E.AD7EE1F6--
